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DETAILED ACTION 

1 . The amendment filed 2/1 4/2006 has been placed of record in the file. 

2. Claims 1, 10 5 15, 21, 25, 30, 37, 42, and 47 have been amended. 

3 . Claims 51-58 and 6 1 -66 have been canceled. 

4. Claims 67-78 have been added. 

5. Claims 1-50, 59, 60, and 67-78 are now pending. 

6. The applicant's arguments with respect to claims 1-50, 59, and 60 have been considered 
but are moot in view of the following new grounds of rejection. 

Continued Examination Under 37 CFR 1.114 

7. A request for continued examination under 37 CFR 1.114, including the fee set forth in 
37 CFR 1.17(e), was filed in this application after final rejection. Since this application is 
eligible for continued examination under 37 CFR 1 . 1 1 4, and the fee set forth in 37 CFR 1 . 1 7(e) 
has been timely paid, the finality of the previous office action has been withdrawn pursuant to 37 
CFR 1.114. The applicant's submission filed on 12/22/2005 has been entered. 

Claim Rejections - 35 USC § 112 

8. The following is a quotation of the second paragraph of 35 U.S.C. 112: 

The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the 
subject matter which the applicant regards as his invention. 

9. Claims 1-14, 37-46, 59, 60, 67-69, and 73-75 are rejected under 35 U.S.C. 1 12, second 
paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject 
matter which applicant regards as the invention. 
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10. Independent claims 1,10, 37, and 42 recite "wherein said receiving, said generating and 
said sending are performed in an aggregation device implemented as a single device" or the like. 
This clause makes the claims indefinite as it states that the sending step is performed in the 
aggregation device. In order to perform the step of "sending said aggregated request packet on 
said communication network to a peer aggregation device" in a single aggregation device, the 
aggregation device would have to include the communication network and the peer aggregation 
device. This, of course, is nonsensical and is inconsistent with the applicant's disclosure and 
other claim language. Thus, the scope of claims 1, 10, 37, and 42 is unclear. For the purpose of 
applying prior art it will be assumed that the aggregation device performs the act of sending and 
that the whole sending step is not performed in the aggregation device. 

11. Claims 2-9, 11-14, 38-41, 43-46, 59, 60, 67-69, and 73-75 are rejected due to their 
dependence on claims 1, 10, 37, and 42. 

Claim Rejections - 35 USC § 103 

12. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

13. Claims 1-4, 8-10, 14, 21-23, 25, 29, 30, 35-40, 42, 46-50, 59, 60, 69, 72, 75, and 78 are 
rejected under 35 U.S.C. 103(a) as being unpatentable over Ketcham (U.S. Patent Number 
6,721,334) in view of Pereira (U.S. Patent Number 5,781,726). 
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14. Ketcham disclosed a method for improving the efficiency of a packet-based network by 
using aggregate packets. In an analogous art, Pereira disclosed a method for managing polling 
traffic in a set of connection oriented sessions between end stations in a network. Both systems 
deal with data transfer from at least one end node, through a first router or edge device, through a 
second router or edge device, and to at least one second end node. 

1 5. Concerning the independent claims, although Ketcham describes a system in which 
different types of data packets can be aggregated together, he did not explicitly state the use of a 
keep-alive message or poll request. However, Pereira' s system is focused on the polling of 
point-to-point devices and explicitly states the use of a poll request from a first to a second end 
system and a poll response from the second to the first end system. It would have been obvious 
to one of ordinary skill in the art at the time of the applicant's invention to modify the system of 
Ketcham by adding the ability to use keep-alive messages as the data packets as provided by 
Pereira. Here the combination would satisfy the need for an improved connection oriented 
protocol for systems that maintain a number of end users that share a common link. See Pereira, 
column 4 5 lines 12-17. This rationale also applies to those dependent claims utilizing the same 
combination. 

1 6. Thereby, the combination of Ketcham and Pereira discloses: 
• <Claim 1> 

A method of processing a plurality of keep-alive messages generated by a corresponding 
plurality of end systems, each of said plurality of keep-alive messages being designed to 
request the status of a corresponding point to point (PPP) session implemented on a 
communication network, said method comprising: receiving in an aggregation device 



Application/Control Number: 09/785,884 Page 5 

Art Unit: 2152 

(Ketcham, figure 4, item 308) said plurality of keep-alive messages (Pereira, column 4, 
lines 31-34); generating in said aggregation device an aggregated request packet which 
indicates that the status of said PPP sessions is requested (Ketcham, column 7, line 62 
through column 8, line 4, wherein the aggregated packet contains the poll requests as 
disclosed by Pereira); and sending said aggregated request packet on said communication 
network to a peer aggregation device (Ketcham, figure 4, item 314), wherein said 
receiving, said generating and said sending are performed in an aggregation device 
implemented as a single device (Ketcham, figure 4, item 308). 

• <Claim 2> 

The method of claim 1, further comprising: receiving said aggregated request packet in 
said peer aggregation device (Ketcham, column 8, lines 15-22); indicating the status of 
said plurality of sessions in an aggregated reply packet (Pereira, column 6, lines 1-6, 
wherein Pereira's response polls may be aggregated at Ketcham's router 314); and 
sending said aggregated reply packet to said aggregation device (Ketcham, figure 4, 
inherently data packets can also flow from router 314 to router 308). 

• <Claim 3> 

The method of claim 1, further comprising receiving in said aggregation device an 
aggregated reply packet from said peer aggregation device, wherein said aggregated reply 
packet indicates the status of at least some of said plurality of PPP sessions (Pereira, 
column 6, lines 1-6). 
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• <Claim 4> 

The method of claim 3, further comprising sending from said aggregation device a proxy 
keep-alive reply message to one of said plurality of end systems originating a 
corresponding one of said keep alive-messages without waiting for said aggregated reply 
packet (Pereira, column 5, lines 45-47). 

• <Claim 8> 

The method of claim 1 , wherein said communication network is implemented using one 
of frame relay, ATM and IP networks (Ketcham, column 1, lines 33-48). 

• <Claim 9> 

The method of claim 1, wherein said aggregation device is one of a network access server 
and home gateway (Ketcham, column 4, lines 37-43). 

• <Claim 10> 

A method of processing an aggregated request packet in an aggregation device, wherein 
said aggregated request packet indicates that the status of a plurality of point-to-point 
sessions are requested, said method comprising: examining said aggregated request 
packet to determine said plurality of point-to-point sessions (Ketcham, column 8, lines 
15-22, wherein the aggregated packet contains the poll requests as disclosed by Pereira); 
determining the status of each of said plurality of point-to-point sessions (Pereira, column 
6, lines 1-6 and 50-55); generating an aggregated reply packet indicating the status of 
said plurality of point- to-point sessions (Pereira, column 6, lines 1-6, wherein Pereira' s 
response polls may be aggregated at Ketcham' s router 314); and sending said aggregated 
reply packet to said peer aggregation device (Ketcham, figure 4, inherently data packets 
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can also flow from router 314 to router 308), wherein said examining, said determining, 
said generating and said sending are performed in said aggregation device implemented 
as a single device (Ketcham, figure 4, item 314). 

• <Claim 14> 

The method of claim 10, wherein said aggregation device comprises one of a network 
access server (NAS) and a home gateway implemented in a communication network 
(Ketcham, column 4, lines 37-43). 

• <Claim21> 

An aggregation device for processing a plurality of keep-alive messages generated by a 
corresponding plurality of end systems, each of said plurality of keep-alive messages 
being designed to request the status of a corresponding point to point (PPP) session 
implemented on a communication network, said aggregation device comprising: first 
means for receiving said plurality of keep-alive messages (Ketcham, figure 4, item 308 
and Pereira, column 4, lines 31-34); means for generating an aggregated request packet 
which indicates that the status of said PPP sessions is requested (Ketcham, column 7, line 
62 through column 8, line 4, wherein the aggregated packet contains the poll requests as 
disclosed by Pereira); and means for sending said aggregated request packet on said 
communication network to a peer aggregation device (Ketcham, figure 4, item 314), 
wherein said means for receiving, said means for generating and said means for sending 
are contained in said aggregation device implemented as a single device (Ketcham, figure 
4, item 308). 
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• <Claim 22> 

The aggregation device of claim 21, further comprising second means for receiving an 
aggregated reply packet from said peer aggregation device (Ketcham, figure 4, inherently 
data packets can also flow from router 314 to router 308), wherein said aggregated reply 
packet indicates the status of at least some of said plurality of PPP sessions (Pereira, 
column 6, lines 1-6). 

• <Claim 23> 

The aggregation device of claim 22, further comprising means for sending a proxy keep- 
alive reply message to one of said plurality of end systems originating a corresponding 
one of said keep alive-messages without waiting for said aggregated reply packet 
(Pereira, column 5, lines 45-47). 

• <Claim 25> 

An aggregation device for processing an aggregated request packet, wherein said 
aggregated request packet indicates that the status of a plurality of point-to-point sessions 
are requested, said aggregation device comprising: means for examining said aggregated 
request packet to determine said plurality of point-to-point sessions (Ketcham, column 8, 
lines 15-22, wherein the aggregated packet contains the poll requests as disclosed by 
Pereira); means for determining the status of each of said plurality of point-to-point 
sessions (Pereira, column 6, lines 1-6 and 50-55); means for generating an aggregated 
reply packet indicating the status of said plurality of point-to-point sessions (Pereira, 
column 6, lines 1-6, wherein Pereira's response polls may be aggregated at Ketcham's 
router 314); and means for sending said aggregated reply packet to said peer aggregation 
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device (Ketcham, figure 4, inherently data packets can also flow from router 314 to router 
308), wherein said means for examining, said means for determining, said means for 
generating and said means for sending are implemented in said aggregation device 
implemented as a single device (Ketcham, figure 4, item 314). 

• <Claim 29> 

The aggregation device of claim 25, wherein said aggregation device comprises one of a 
network access server (NAS) and a home gateway implemented in a communication 
network (Ketcham, column 4, lines 37-43). 

• <Claim 30> 

An aggregation device for processing an aggregated request packet, wherein said 
aggregated request packet indicates that the status of a plurality of point-to-point sessions 
are requested, said aggregation device comprising: an input interface receiving said 
aggregated request packet (Ketcham, figure 4, item 314, wherein the aggregated packet 
contains the poll requests as disclosed by Pereira); a de-encapsulator examining said 
aggregated request packet to determine that said aggregated request packet relates to 
requesting the status of point-to-point sessions (Ketcham, column 8, lines 15-22); a reply 
generator determining the status of each of said plurality of point-to-point sessions, and 
generating an aggregated reply packet indicating the status of said plurality of point-to- 
point sessions (Pereira, column 6, lines 1-6, wherein Pereira's response polls may be 
aggregated at Ketcham' s router 314); and an output interface sending said aggregated 
reply packet to said peer aggregation device (Ketcham, figure 4, inherently data packets 
can also flow from router 314 to router 308), wherein said input interface, said de- 
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encapsulator, said reply generator and said output interface are contained in said 
aggregation device implemented as a single device (Ketcham, figure 4, item 314). 

• <Claim 35> 

The aggregation device of claim 30, further comprising a keep-alive processor coupled to 
said de-encapsulator, wherein said keep-alive processor examines said aggregated request 
packet to determine that status of point-to-point sessions is requested and causes said 
reply generator to generate said aggregated reply packet (Ketcham, column 8, lines 15-22 
and Pereira, column 6, lines 1-6). 

• <Claim 36> 

The aggregation device of claim 30, wherein said aggregation device comprises one of a 
network access server (NAS) and a home gateway implemented in a communication 
network (Ketcham, column 4, lines 37-43), 

• <Claim 37> 

A computer-readable medium carrying one or more sequences of instructions for causing 
a aggregation device to process a plurality of keep-alive messages generated by a 
corresponding plurality of end systems, each of said plurality of keep-alive messages 
being designed to request the status of a corresponding point to point (PPP) session 
implemented on a communication network, wherein execution of said one or more 
sequences of instructions by one or more processors contained in said aggregation device 
causes said one or more processors to perform the actions of: receiving in an aggregation 
device (Ketcham, figure 4, item 308) said plurality of keep-alive messages (Pereira, 
column 4, lines 31-34); generating in said aggregation device an aggregated request 
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packet which indicates that the status of said PPP sessions is requested (Ketcham, column 
7, line 62 through column 8, line 4, wherein the aggregated packet contains the poll 
requests as disclosed by Pereira); and sending said aggregated request packet on said 
communication network to a peer aggregation device (Ketcham, figure 4, item 314), 
wherein said receiving, said generating and said sending are performed in an aggregation 
device implemented as a single device (Ketcham, figure 4, item 308). 

• <Claim 38> 

The computer-readable medium of claim 37, further comprising: receiving said 
aggregated request packet in said peer aggregation device (Ketcham, column 8, lines 15- 
22); indicating the status of said plurality of sessions in an aggregated reply packet 
(Pereira, column 6, lines 1-6, wherein Pereira's response polls may be aggregated at 
Ketcham's router 314); and sending said aggregated reply packet to said aggregation 
device (Ketcham, figure 4, inherently data packets can also flow from router 314 to router 
308). 

• <Claim 39> 

The computer-readable medium of claim 37, further comprising receiving in said 
aggregation device an aggregated reply packet from said peer aggregation device, 
wherein said aggregated reply packet indicates the status of at least some of said plurality 
of PPP sessions (Pereira, column 6, lines 1-6). 

• <Claim 40> 

The computer-readable medium of claim 39, further comprising sending a proxy keep- 
alive reply message to one of said plurality of end systems originating a corresponding 
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one of said keep alive-messages without waiting for said aggregated reply packet 
(Pereira, column 5, lines 45-47). 
• <Claim 42> 

A computer-readable medium carrying one or more sequences of instructions for causing 
an aggregation device to process an aggregated request packet, wherein said aggregated 
request packet indicates that the status of a plurality of point-to-point sessions are 
requested, wherein execution of said one or more sequences of instructions by one or 
more processors contained in said aggregation device causes said one or more processors 
to perform the actions of: examining said aggregated request packet to determine said 
plurality of point-to-point sessions (Ketcham, column 8, lines 15-22, wherein the 
aggregated packet contains the poll requests as disclosed by Pereira); determining the 
status of each of said plurality of point-to-point sessions (Pereira, column 6, lines 1-6 and 
50-55); generating an aggregated reply packet indicating the status of said plurality of 
point- to-point sessions (Pereira, column 6, lines 1-6, wherein Pereira' s response polls 
may be aggregated at Ketcham 's router 314); and sending said aggregated reply packet to 
said peer aggregation device (Ketcham, figure 4, inherently data packets can also flow 
from router 314 to router 308), wherein said examining, said determining, said generating 
and said sending are performed in said aggregation device implemented as a single 
device (Ketcham, figure 4, item 314). 
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• <Claim 46> 

The computer-readable medium of claim 42, wherein said aggregation device comprises 
one of a network access server (NAS) and a home gateway implemented in a 
communication network (Ketcham, column 4, lines 37-43). 

• <Claim 47> 

A communication network comprising: a first aggregation device (Ketcham, figure 4, 
item 308) receiving a plurality of keep-alive messages (Pereira, column 4, lines 31-34) 
generated by a corresponding plurality of end systems, each of said plurality of keep- 
alive messages being designed to request the status of a corresponding point to point 
(PPP) session implemented on said communication network, said first aggregation device 
generating an aggregated request packet which indicates that the status of said PPP 
sessions is requested (Ketcham, column 7, line 62 through column 8, line 4, wherein the 
aggregated packet contains the poll requests as disclosed by Pereira), and sending said 
aggregated request packet (Ketcham, column 7, line 62 through column 8, line 4); and a 
peer aggregation device (Ketcham, figure 4, item 314) receiving said aggregated request 
packet and indicating the status of said plurality of sessions in an aggregated reply packet 
(Pereira, column 6, lines 1-6, wherein Pereira' s response polls may be aggregated at 
Ketcham 's router 314), said peer aggregation packet sending said aggregated reply packet 
to said first aggregation device (Ketcham, figure 4, inherently data packets can also flow 
from router 314 to router 308), wherein each of said first aggregation device and said 
peer aggregation device is implemented as a single device (Ketcham, figure 4, items 308 
and 314). 
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• <Claim 48> 

The communication network of claim 47, wherein said first aggregation device is located 
at an edge of said communication networks (Ketcham, figure 4, item 308). 

• <Claim 49> 

The communication network of claim 48, further comprising an access network coupling 
said first aggregation device to said corresponding plurality of end systems, wherein said 
plurality of keep-alive messages are received on said access network (Ketcham, figure 4, 
item 106). 

• <Claim 50> 

The communication network of claim 49, wherein said first aggregation device and said 
peer aggregation device respectively comprise a network access server (NAS) and a 
home gateway (Ketcham, column 4, lines 37-43). 

• <Claim 59> 

The method of claim 1 , wherein said aggregation device is physically separate from said 
plurality of end systems (Ketcham, figure 4, item 308). 

• <Claim 60> 

The method of claim 10, wherein said aggregation device is physically separate from said 
plurality of end systems (Ketcham, figure 4, item 308). 

• <Claim 69> 

The method of claim 1 , wherein each of said PPP sessions terminates at a home gateway, 
and wherein said aggregation device comprises a switching device and is in the path of 
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each of said PPP sessions from a corresponding one of said plurality of end systems to 
said home gateway (Ketcham, figure 4, item 308). 

• <Claim 72> 

The aggregation device of claim 30, wherein each of said PPP sessions terminates at a 
home gateway, and wherein said aggregation device comprises a switching device and is 
in the path of each of said PPP sessions from a corresponding one of said plurality of end 
systems to said home gateway (Ketcham, figure 4, item 314). 

• <Claim 75> 

The computer readable medium of claim 37, wherein each of said PPP sessions 
terminates at a home gateway, and wherein said aggregation device comprises a 
switching device and is in the path of each of said PPP sessions from a corresponding one 
of said plurality of end systems to said home gateway (Ketcham, figure 4, item 308). 

• <Claim 78> 

The aggregation device of claim 21, wherein each of said PPP sessions terminates at a 
home gateway, and wherein said aggregation device comprises a switching device and is 
in the path of each of said PPP sessions from a corresponding one of said plurality of end 
systems to said home gateway (Ketcham, figure 4, item 308). 
Since the combination of Ketcham and Pereira discloses all of the above limitations, claims 1-4, 
8-10, 14, 21-23, 25, 29, 30, 35-40, 42, 46-50, 59, 60, 69, 72, 75, and 78 are rejected. 
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17. Claims 5-7, 1 1, 13 24, 26, 28, 31, 32, 34, 41, 43, and 45 are rejected under 35 U.S.C. 
103(a) as being unpatentable over Ketcham in view of Pereira, as applied above, further in view 
of Chao et al. (U.S. Patent Number 5,964,837), hereinafter referred to as Chao. 

18. The combination of Ketcham and Pereira disclosed a method for managing polling traffic 
in a set of connection oriented sessions between end stations in a network that uses aggregation 
of packets. In an analogous art, Chao disclosed a method of monitoring the topology of a 
network using polling and event-monitoring. Just as the combination of Ketcham and Pereira, 
Chao's system is utilized in point-to-point networks. 

1 9. Concerning claim 5, although the combination of Ketcham and Pereira did not explicitly 
state the use of a table to track the status of sessions in the network, Chao's main focus is a table 
or topology map, containing information about the operability of nodes in his system. It would 
have been obvious to one of ordinary skill in the art at the time of the applicant's invention to 
modify the combination of Ketcham and Pereira by adding a status table as provided by Chao. 
Here the combination satisfies the need for an improved method of monitoring a point-to-point 
network. See Chao, column 2, lines 15-24. This rationale also applies to other similar dependent 
claims utilizing the same combination. 

20. Thereby, the combination of Ketcham, Pereira, and Chao discloses: 
• <Claim 5> 

The method of claim 4, further comprising: maintaining a remote status table in said 
aggregation device, wherein said remote status table indicates the status of sessions 
supported by said aggregation device (Chao, column 5, lines 46-50); updating said 
remote status table with the information in said aggregated reply packet (Chao, column 6, 
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lines 1-13); and generating said proxy keep-alive reply according to said remote status 
table (Chao, column 6, lines 55-65). 

• <Claim 6> 

The method of claim 5, wherein said proxy keep-alive message indicates that the 
corresponding session is alive/OK when a first keep-alive message is received for the 
corresponding session (Pereira, column 10, lines 29-38). 

• <Claim 7> 

The method of claim 6, further comprising initializing the status of each of said session to 
alive/OK such that said proxy keep-alive message in response to said first keep-alive 
message indicates alive/OK status (Pereira, column 10, lines 18-28). 

• <Claimll> 

The method of claim 10, wherein said determining comprises accessing a local status 
table which contains the status information of at least some of said plurality of point- to- 
point sessions (Chao, column 8, lines 52-58). 

• <Claim 13> 

The method of claim 10, wherein said generating comprises setting a bit to one logical 
value to indicate that a corresponding one of said plurality of sessions is OK/alive, and to 
another logical value to indicate that said corresponding one of said plurality of session 
not OK/alive (Chao, column 5, lines 50-53). 

• <Claim 24> 

The aggregation device of claim 23, further comprising: means for maintaining a remote 
status table in said aggregation device, wherein said remote status table indicates the 
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status of sessions supported by said aggregation device (Chao, column 5, lines 46-50); 
means for updating said remote status table with the information in said aggregated reply 
packet (Chao, column 6, lines 1-13); and means for generating said proxy keep-alive 
reply according to said remote status table (Chao, column 6, lines 55-65). 

• <Claim 26> 

The aggregation device of claim 25, wherein said means for determining comprises 
means for accessing a local status table which contains the status information of at least 
some of said plurality of point-to-point sessions (Chao, column 8, lines 52-58). 

• <Claim 28> 

The aggregation device of claim 25, wherein said means for generating sets a bit in said 
aggregated reply packet to one logical value to indicate that a corresponding one of said 
plurality of sessions is OK/alive, and to another logical value to indicate that said 
corresponding one of said plurality of session not OK/alive (Chao, column 5, lines 50- 
53). 

• <Claim31> 

The aggregation device of claim 30, further comprising a local status table storing the 
status information of at least some of said plurality of point-to-point sessions, wherein 
said reply generator determines the status of said at least some of said plurality of point- 
to- point sessions by accessing said local status table (Chao, column 8, lines 52-58). 
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• <Claim 32> 

The aggregation device of claim 31, further comprising a session manager updating the 
status of said plurality of point-to-point sessions in said local status table (Chao, column 
7, lines 64-66). 

• <Claim 34> 

The aggregation device of claim 30, wherein said reply generator sets a bit in said 
aggregated reply packet to one logical value to indicate that a corresponding one of said 
plurality of sessions is OK/alive, and to another logical value to indicate that said 
corresponding one of said plurality of session not OK/alive (Chao, column 5, lines 50- 
53). 

• <Claim41> 

The computer-readable medium of claim 40, further comprising: maintaining a remote 
status table in said aggregation device, wherein said remote status table indicates the 
status of sessions supported by said aggregation device (Chao, column 5, lines 46-50); 
updating said remote status table with the information in said aggregated reply packet 
(Chao, column 6, lines 1-13); and generating said proxy keep-alive reply according to 
said remote status table (Chao, column 6, lines 55-65). 

• <Claim 43> 

The computer-readable medium of claim 42, wherein said determining comprises 
accessing a local status table which contains the status information of at least some of 
said plurality of point-to-point sessions (Chao, column 8, lines 52-58). 
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• <Claim 45> 

The computer-readable medium of claim 42, wherein said generating comprises setting a 
bit to one logical value to indicate that a corresponding one of said plurality of sessions is 
OK/alive, and to another logical value to indicate that said corresponding one of said 
plurality of session not OK/alive (Chao, column 5, lines 50-53). 

Since the combination of Ketcham, Pereira, and Chao discloses all of the above limitations, 

claims 5-7, 1 1, 13, 24, 26, 28, 31, 32, 34, 41, 43, and 45 are rejected. 

21. Claims 12, 27, 33, and 44 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Ketcham in view of Pereira further in view of Chao, as applied above, further in view of 
Simpson ("RFC 1661: Point-to-Point Protocol," July 1994). 

22. The combination of Ketcham, Pereira, and Chao disclosed a method for managing polling 
traffic in a set of connection oriented sessions between end stations in a point-to-point network 
by aggregating packets and maintaining a status table. In an analogous art, Simpson disclosed an 
overview of the point-to-point protocol. 

23. Concerning claim 12, although the combination of Ketcham, Pereira, and Chao did not 
explicitly teach the use of a magic number associated with each session, Simpson taught a magic 
number for use with the point-to-point protocol. It would have been obvious to one of ordinary 
skill in the art at the time of the applicant's invention to modify the combination of Ketcham, 
Pereira, and Chao by adding a magic number as provided by Simpson. Again the combination 
satisfies the need for an improved method of monitoring a point-to-point network. See Chao, 
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column 2, lines 15-24. This rationale also applies to other similar dependent claims utilizing the 
same combination. 

24. Thereby, the combination of Ketcham, Pereira, Chao, and Simpson discloses: 

• <Claim \2> 

The method of claim 10, wherein said generating comprises including a client magic 
number associated with each of said plurality of point-to-point sessions (Simpson, pages 
45-47). 

• <Claim 27> 

The aggregation device of claim 25, wherein said means for generating includes a client 
magic number associated with each of said plurality of point-to-point sessions (Simpson, 
pages 45-47). 

• <Claim 33> 

The aggregation device of claim 30, wherein said reply generator includes in said 
aggregated reply packet a client magic number associated with each of said plurality of 
point-to-point sessions (Simpson, pages 45-47). 

• <Claim 44> 

The computer-readable medium of claim 42, wherein said generating comprises 
including a client magic number associated with each of said plurality of point-to-point 
sessions (Simpson, pages 45-47). 

Since the combination of Ketcham, Pereira, Chao, and Simpson discloses all of the above 

limitations, claims 12, 27, 33, and 44 are rejected. 
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25. Claims 15, 16, 67, 68, 70, 71, 73, 74, 76, and 77 are rejected under 35 U.S.C. 103(a) as 
being unpatentable over Ketcham in view of Pereira, as applied above, further in view of 
Rosenberg et al. ("An RTP Payload Format for User Multiplexing," May 1998), hereinafter 
referred to as Rosenberg. 

26. The combination of Ketcham and Pereira disclosed a method for managing polling traffic 
in a set of connection oriented sessions between end stations in a network that uses aggregation 
of packets. In an analogous art, Rosenberg disclosed a method of aggregating RTP data for 
multiple users in a point-to-point system. Just as the combination of Ketcham and Pereira, 
Rosenberg's system is utilized in point-to-point networks. 

27. Concerning claim 15, although the combination of Ketcham and Pereira did not explicitly 
state that the aggregated message includes fewer bits than the sum of the data forming the non- 
aggregated messages, this is a well known result in message aggregation. This is evidenced by 
Rosenberg whose system creates an aggregated message that is smaller than the sum of the 
original messages in order to improve packet efficiency. It would have been obvious to one of 
ordinary skill in the art at the time of the applicant's invention to modify the combination of 
Ketcham and Pereira by adding the ability for the message aggregator to include fewer bits in the 
data than the sum of data forming the plurality of messages together as provided by Rosenberg. 
Here the combination satisfies the need for an improved connection oriented protocol for 
systems that maintain a number of end users that share a common link. See Pereira, column 4, 
lines 12-17. This rationale also applies to similar dependent claims utilizing the same > 
combination. 

28. Thereby, the combination of Ketcham, Pereira, and Rosenberg discloses: 
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• <Claim 15> 

An aggregation device for processing a plurality of keep-alive messages generated by a 
corresponding plurality of end systems, each of said plurality of keep-alive messages 
being designed to request the status of a corresponding point to point (PPP) session 
implemented on a communication network, said aggregation device comprising: an input 
interface receiving said plurality of keep-alive messages (Ketcham, figure 4, item 308 
and Pereira, column 4, lines 31-34); a message aggregator coupled to said input interface, 
said message aggregator examining said plurality of message and generating data 
according to a format indicating that the status of said PPP sessions is requested 
(Ketcham, column 7, line 62 through column 8, line 4, wherein the aggregated packet 
contains the poll requests as disclosed by Pereira), wherein said message aggregator 
includes fewer bits in said data than the sum of data forming said plurality of keep-alive 
messages together (Rosenberg, page 2, paragraph beginning "On the other hand..."); and 
an output interface sending an aggregated request packet on said communication network 
to a peer aggregation device, said aggregated request packet containing said data 
generated by said message aggregator (Ketcham, figure 4, item 314). 

• <Claim 16> 

The aggregation device of claim 15, further comprising an encapsulator encapsulating 
said data in a packet suitable for transmission on said communication network (Pereira, 
column 2, lines 19-25, wherein encapsulation is inherent to PPP). 
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• <Claim 67> 

The method of claim 1 , wherein said generating includes less data in said aggregated 
request packet than the data forming said plurality of keep-alive messages together 
(Rosenberg, page 2, paragraph beginning "On the other hand. . .")■ 

• <Claim 68> 

The method of claim 67, wherein each of said plurality of keep-alive messages contains 
an identifier of a corresponding PPP session, wherein said generating comprises: 
selecting said identifier of each of said plurality of keep-alive messages (Rosenberg, 
pages 3-5, section 2); and forming said aggregated request packet from said identifiers 
(Rosenberg, pages 3-5, section 2), whereby said aggregated request packet contains less 
data than said plurality of keep-alive messages together (Rosenberg, page 2, paragraph 
beginning "On the other hand. . .")• 

• <Claim 70> 

The aggregation device of claim 30, wherein said reply generator includes less data in 
said aggregated request packet than the data forming said plurality of keep-alive 
messages together (Rosenberg, page 2, paragraph beginning "On the other hand. . ."). 

• <Claim71> 

The aggregation device of claim 70, wherein each of said plurality of keep-alive 
messages contains an identifier of a corresponding PPP session, wherein said reply 
generator operates to: select said identifier of each of said plurality of keep-alive 
messages (Rosenberg, pages 3-5, section 2); and form said aggregated request packet 
from said identifiers (Rosenberg, pages 3-5, section 2), whereby said aggregated request 
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packet contains less data than said plurality of keep-alive messages together (Rosenberg, 
page 2, paragraph beginning "On the other hand. . ."). 

• <Claim 73> 

The computer readable medium of claim 37, wherein said generating includes less data in 
said aggregated request packet than the data forming said plurality of keep-alive 
messages together (Rosenberg, page 2, paragraph beginning "On the other hand. . ."). 

• <Claim 74> 

The computer readable medium of claim 73, wherein each of said plurality of keep-alive 
messages contains an identifier of a corresponding PPP session, wherein said generating 
comprises: selecting said identifier of each of said plurality of keep-alive messages 
(Rosenberg, pages 3-5, section 2); and forming said aggregated request packet from said 
identifiers (Rosenberg, pages 3-5, section 2), whereby said aggregated request packet 
contains less data than said plurality of keep-alive messages together (Rosenberg, page 2, 
paragraph beginning "On the other hand. . ."). 

• <Claim 76> 

The aggregation device of claim 21, wherein said means for generating includes less data 
in said aggregated request packet than the data forming said plurality of keep-alive 
messages together (Rosenberg, page 2, paragraph beginning "On the other hand. . ."). 

• <Claim 77> 

The aggregation device of claim 76, wherein each of said plurality of keep-alive 
messages contains an identifier of a corresponding PPP session, wherein said means for 
generating operates to: select said identifier of each of said plurality of keep-alive 
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messages (Rosenberg, pages 3-5, section 2); and form said aggregated request packet 
from said identifiers (Rosenberg, pages 3-5, section 2), whereby said aggregated request 
packet contains less data than said plurality of keep-alive messages together (Rosenberg, 
page 2, paragraph beginning "On the other hand. .."). 

Since the combination of Ketcham, Pereira, and Rosenberg discloses all of the above limitations, 

claims 15, 16, 67, 68, 70, 71, 73, 74, 76, and 77 are rejected. 

29. Claims 17-19 are rejected under 35 U.S.C. 103(a) as being unpatentable over Ketcham in 
view of Pereira further in view of Rosenberg, as applied above, further in view of Chao. 

30. The combination of Ketcham, Pereira, and Rosenberg disclosed a method for managing 
polling traffic in a set of connection oriented sessions between end stations in a network that uses 
aggregation of packets. In an analogous art, Chao disclosed a method of monitoring the 
topology of a network using polling and event-monitoring. Just as the combination of Ketcham, 
Pereira, and Rosenberg, Chao's system is utilized in point-to-point networks. 

31 . Concerning claim 17, although the combination of Ketcham, Pereira, and Rosenberg did 
not explicitly state the use of a table to track the status of sessions in the network, Chao's main 
focus is a table or topology map, containing information about the operability of nodes in his 
system. It would have been obvious to one of ordinary skill in the art at the time of the 
applicant's invention to modify the combination of Ketcham, Pereira, and Rosenberg by adding a 
status table as provided by Chao. Here the combination satisfies the need for an improved 
method of monitoring a point-to-point network. See Chao, column 2, lines 15-24. This rationale 
also applies to other similar dependent claims utilizing the same combination. 
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32. Thereby, the combination of Ketcham, Pereira, Rosenberg, and Chao discloses: 

• <Claim 17> 

The aggregation device of claim 16, further comprising: a remote status table indicating 
the status of sessions supported by said aggregation device (Chao, column 5, lines 46- 
50); and a de-aggregator receiving an aggregated reply packet from said peer aggregation 
device, wherein said aggregated reply packet indicates the status of at least some of said 
plurality of PPP sessions, said de-aggregator updating said remote status table with the 
information in said aggregated reply packet (Chao, column 6, lines 1-13). 

• <Claim 18> 

The aggregation device of claim 17, further comprising a proxy reply unit sending a 
proxy keep-alive reply message to one of said plurality of end systems originating a 
corresponding one of said keep alive-messages without waiting for said aggregated reply 
packet (Pereira, column 5, lines 45-47). 

• <Claim 19> 

The invention of claim 1 8, wherein said aggregation device comprises a network access 

server (Ketcham, column 4, lines 37-43). 
Since the combination of Ketcham, Pereira, Rosenberg, and Chao discloses all of the above 
limitations, claims 17-19 are rejected. 

33. Claim 20 is rejected under 35 U.S.C. 103(a) as being unpatentable over Ketcham in view 
of Pereira further in view of Rosenberg, further in view of Chao, as applied above, further in 
view of Simpson. 
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34. The combination of Ketcham, Pereira, Rosenberg, and Chao disclosed a method for 
managing polling traffic in a set of connection oriented sessions between end stations in a point- 
to-point network by aggregating packets and maintaining a status table. In an analogous art, 
Simpson disclosed an overview of the point-to-point protocol. 

35. Concerning claim 20, although the combination of Ketcham, Pereira, Rosenberg, and 
Chao did not explicitly teach the use of a magic number associated with each session, Simpson 
taught a magic number for use with the point-to-point protocol. It would have been obvious to 
one of ordinary skill in the art at the time of the applicant's invention to modify the combination 
of Ketcham, Pereira, Rosenberg, and Chao by adding a magic number as provided by Simpson. 
Again the combination satisfies the need for an improved method of monitoring a point-to-point 
network. See Chao, column 2, lines 15-24. 

36. Thereby, the combination of Ketcham, Pereira, Rosenberg, Chao, and Simpson discloses: 
• <Claim 20> 

The aggregation device of claim 18, wherein said aggregated request packet contains a 
magic number related to each of the corresponding sessions (Simpson, pages 45-47). 

Since the combination of Ketcham, Pereira, Rosenberg, Chao, and Simpson discloses all of the 

above limitations, claim 20 is rejected. 

Conclusion 

37. The prior art made of record and not relied upon is considered pertinent to the applicant's 
disclosure. 
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• Cox et al. (U.S. Patent Number 5,535,335) disclosed a network of communicating 
resources in which the statuses of real resources may be propagated to higher aggregate 
resource whose own statuses are based upon the statuses of the real resources. 

• Mahler et al. (U.S. Patent Number 6,542,504) disclosed a method for the compression of 
packet header information of packets transmitted on a point-to-point link. 

• Mohaban et al. (U.S. Patent Number 7,002,993) disclosed a method for aggregating 
multiple media packets under a single header in order to improve end-to-end bandwidth 
efficiency. 

38. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Victor Lesniewski whose telephone number is 571-272-3987. 
The examiner can normally be reached on Monday through Thursday. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Bunjob Jaroenchonwanit can be reached on 571-272-3913. The fax phone number 
for the organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). V 
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